這次要講的情境，也是我以前在工作現場遇過的需求：每日環境巡檢。

主管要求維運人員每天早上進辦公室後，先檢查多個環境的 Kubernetes 與周邊監控系統。確認服務有沒有正常、截圖，最後把結果整理到 ticket，再到群組回報。

乍聽之下很合理。每天有人看過，主管也能收到一份紀錄，一切好棒棒。只是我愈想愈不對勁。

環境已經有 Prometheus、Grafana、log 系統和告警機制。這些系統一天二十四小時都在收 metrics、logs 與告警。結果每天早上還要派一個人，打開同一批頁面，用肉眼確認幾張圖看起來順眼，再截圖證明自己看過。

那監控系統到底在忙什麼？

所以我先去找維運人員聊聊，看這個需求到底想確認什麼。

我看見的每日巡檢

實際訪談維運人員後，他們描述的「每天早上看平台」流程如下：

1. 逐一打開不同環境的 Kubernetes 管理介面，確認各 Node 與 Pod 狀態。
2. 查看監控系統有沒有正常執行。
3. 截圖、整理 ticket，再到群組回報今天有沒有問題。

看起來合理，但我總覺得少了什麼。想了一下才發現，這套流程只看到「現在」，完全沒有查看 Grafana 裡的歷史資料。

假設半夜三點某個 Node 曾經短暫 NotReady，幾分鐘後又自行恢復。如果當時告警傳遞也發生問題，等到早上打開管理介面時，畫面可能已經恢復正常。維運人員只看當下狀態，很容易得到「系統都正常」的結論。

每天只交幾張截圖，久了很容易流於形式，也沒有發揮真正的巡檢功用。

所以巡檢真的要發揮作用的話，應該也要去查看 Grafana 的歷史資料，確認半夜到早上這段時間有沒有發生過異常。這樣或許可以找到一些問題，避免漏掉半夜短暫發生、最後又自行恢復的異常。

重新整理需求

每天都要做的事，又是固定的流程，當然要交給自動化來處理，所以先整理一下目前的人工流程與可以改善的地方。

1. 檢查 Kubernetes 的 Control Plane 核心服務、Node 與 Workload 是否正常，還有基本的 CPU、Memory 使用率等資訊。
2. 檢查監控系統是否正常。
3. 查看這段時間出現過的告警與 Kubernetes Event。
4. 發現異常後，透過監控系統查詢問題。
5. 整理結果，輸出報告。

人工執行這套流程時，通常會透過 Grafana 統一查看。前提是需要的 metrics、logs 與 Kubernetes Event 都已經被收集，並在 Grafana 設定好 Data Source 與 dashboard。至於程式應該沿用 Grafana，還是直接查詢底層監控系統，接下來再討論。

哪些資料可以用

這次實驗環境使用 Grafana、Prometheus、Alertmanager 與 Loki。Prometheus 收集 metrics，Loki 保存 logs 與 Kubernetes Event，Grafana 則負責呈現這些資料。

這些系統都有 API 可以查詢。巡檢程式要直接連到 Prometheus 與 Loki，還是統一透過 Grafana 查詢，下一篇設計架構時再討論。

每日巡檢的內容

一般來說是看 Kubernetes 平台層的相關指標，包含 Control Plane、Node、Workload 與儲存空間。再加上監控系統本身的狀態，以及這段時間出現過的告警與 Kubernetes Event。

我把巡檢內容整理成幾個項目：

清單列到這裡，我突然愈寫愈心虛。

這些項目既然都知道要查什麼，也能定義多少算異常，那為什麼不直接設定告警？

Node NotReady、容器 OOMKilled、PV 快要寫滿、etcd 沒有 leader，這些都是常見的 Kubernetes 告警。真的發生時，團隊應該立刻收到通知。等到隔天早上巡檢才發現，環境可能已經燒了一整晚，這個反應速度實在有點感人。

所以這個需求愈想愈奇怪。長官想知道環境是否正常，最後卻多出一個每天早上靠人確認的流程。監控系統明明整天都在工作，我們又替它安排一位人類晨間值日生。

每日巡檢的用途

吐槽歸吐槽，但長官交代的需求還是得做。那我只好繼續想，這份每日巡檢能不能補到告警沒有處理好的地方。

第一種情況是監控系統自己出問題。

在前面的假設情境裡，即使 Prometheus 已經發現異常，通知仍可能因為 Alertmanager 連線中斷而沒有送出。

巡檢程式可以回頭檢查整段巡檢期間內，Prometheus 是否持續收到資料、告警規則有沒有執行失敗，以及刻意持續觸發的 Watchdog 測試告警是否曾經中斷。接著再確認同一段期間內 Prometheus 與 Alertmanager 的連線狀態，判斷沒有收到告警究竟是環境平穩，還是告警流程曾經出問題。

第二種情況是根本沒有設定對應的告警。

巡檢報告可能剛好找到一個長期被忽略的指標，或發現某種 Kubernetes Event 一直重複發生。這些問題被確認後，合理的後續應該是補上告警規則。一直靠每天巡檢重複發現同一件事，這套流程大概哪裡有問題。

當整套監控資料都沒有留下時，巡檢程式也無法通靈出當時發生什麼。它能做的是明確回報資料不完整，避免在沒有數據的情況下產生一份全部正常的報告。

所以我先把每日巡檢的定位縮小。即時問題仍然交給告警處理；每日巡檢負責補看監控系統是否失效、告警規則是否有漏網之魚，以及昨天到今天留下哪些需要追查的紀錄。

至於為了這幾件事，每天產生一份巡檢報告到底有沒有多此一舉，就留給大家自行思考。

報告要呈現內容

接下來討論每日巡檢報告內容想呈現什麼。

我希望維運人員拿到報告後，可以先快速知道昨天到今天有哪些項目正常、哪些項目需要注意。遇到異常時，也能繼續查看實際數值、調查結論與相關證據，確認這個判斷是怎麼來的。

當程式找到沒有通過的項目時，會再交給 AI 查詢相關證據，整理這次可能的原因，以及目前還無法確認的事情。

整理後，報告大致需要呈現以下內容：

• 巡檢的開始與結束時間。
• 每個項目的狀態與實際數值。
• 異常項目的風險、一般建議與本次調查結論。
• 支撐調查結論的證據與目前還查不到的事情。
• PASS、WARN、FAIL 與 UNKNOWN 四種狀態。UNKNOWN 代表資料不足，不能直接當成環境正常。

這些狀態由程式根據固定規則產生，風險與一般建議也會預先寫在檢查規則裡。AI 負責調查這次發生的事情，維運人員看到報告後，再決定要不要處理。

結論

整理需求後，預計的操作方式如下:

我希望維運人員早上只需要執行每日巡檢 Skill。接下來由程式取得從上一份報告到現在的監控資料，執行固定檢查，再讓 AI 調查沒有通過的項目，最後產生一份報告。

如果流程能照預期運作，維運人員就不用再逐頁打開 Kubernetes 和 Grafana，也不用自己截圖、抄數值與整理格式。他只需要檢查報告中的判定與證據，再決定後續怎麼處理。

整個流程仍然保留人類的控制權。Skill 由維運人員主動執行，AI 只負責查詢與整理，不會修改 Kubernetes 資源。

整理後，這次要做的系統需要具備以下能力：

1. 自動算出完整的巡檢期間。
2. 透過 API 查詢 metrics、logs、告警與 Kubernetes Event。
3. 先確認監控資料本身是否正常。
4. 根據固定規則產生 PASS、WARN、FAIL 或 UNKNOWN。
5. 只把未通過與無法判定的項目交給 AI 調查。
6. 保留 query、數值、證據、推論與目前查不到的事情。
7. 產生一份讓維運人員可以直接檢查的每日報告。
8. 全程維持唯讀，由人決定後續處理方式。

這份報告可能會在監控系統失效時多提供一道檢查，也可能只是再次證明這些巡檢項目早就該設定告警。反正長官的需求已經來了，我決定先把它做完，至於是不是多此一舉，就留到實際跑完再說。

下一篇開始設計架構，看看資料該從哪裡取得、固定規則放在哪裡、AI 可以使用哪些工具，以及最後怎麼產生報告。

今天就先寫到這，我們明天見！